As various forms of distributed computing, such as cloud computing, have come to dominate the computing landscape, security has become a bottleneck issue that currently prevents the complete migration of various capabilities and systems associated with sensitive data, such as financial data, to cloud-based infrastructures, and/or other distributive computing models. This is because any vulnerability in any of the often numerous virtual assets provided and/or utilized in a cloud-based infrastructure, such as operating systems, virtual machines and virtual server instances, connectivity, etc., represents a potential threat. Consequently, the number, and variety, of potential vulnerabilities can be overwhelming and many currently available vulnerability management approaches lack the ability to track and control these potentially numerous vulnerabilities in any reasonably comprehensive, or even logical, manner.
As noted above, the situation is particularly problematic in cases where sensitive data, such as financial data, is being provided to, processed by, utilized by, and/or distributed by, the various virtual assets, systems, services, and applications within the cloud. This is because exploitation of vulnerabilities in a given virtual asset, system, service, or application can yield devastating results to the owners, even if the breach is an isolated occurrence and is of limited duration. That is to say, with many types of data, developing or deploying a remedy for a vulnerability after that vulnerability has been exploited is no solution at all because irreparable damage may have already been done.
Consequently, the current approaches to vulnerability management that typically involve addressing vulnerabilities on an ad-hoc basis as they arise, or in a simplistic, uncoordinated, static, and largely manual, manner are no longer acceptable. Indeed, in order for applications and systems that process sensitive data to fully migrate to a cloud-based infrastructure, security issues and vulnerabilities must be addressed in a proactive, anticipatory, and comprehensive manner, where the security and invulnerability to attack of virtual assets is verified well before any potential attack can possibly occur, e.g. before deployment and publishing in a production environment.
However, currently, this type of comprehensive approach to vulnerability management and verification is largely unavailable. In addition, in the few cases where a comprehensive approach to vulnerability management and verification is attempted, the vulnerabilities are typically analyzed after deployment of the virtual assets and then each virtual asset is individually verified in the production environment. Consequently, currently, vulnerability management and verification is prohibitively expensive and resource intensive, often requiring significant amounts of dedicated hardware, software, and human administrators that are still often utilized in an ad-hoc manner.
In addition, currently, virtual asset vulnerability analysis and verification management is typically done after the virtual assets are deployed in the computing environment in which they are intended to be used, i.e., in the production computing environment. However, when the virtual assets are deployed in a production computing environment it is often the case that one or more connectivity restrictions are imposed on the virtual assets in the production computing environment. That is to say, when virtual assets are deployed in a production computing environment, they are often deployed in Virtual Private Clouds (VPCs), in designated subnets, under the control of network access control lists, in various security groups, and/or in any other connectivity controlled environment created by the imposition of one or more connectivity restrictions, as discussed herein, and/or as known in the art at the time of filing, and/or as developed after the time of filing.
Given that one or more connectivity restrictions are imposed on the virtual assets in the production computing environment, when a virtual asset is subjected to vulnerability analysis and verified in the production computing environment, there is no way for the verification system to check for vulnerabilities that may be present in a situation where one or more of the connectivity restrictions have been removed. In short, if a given virtual asset is restricted to a specific type of connectivity in a production computing environment, then any vulnerability analysis and verification process can only be performed on the specific type of connectivity provided to the virtual asset in the production computing environment. As a result, no vulnerability testing or verification can be performed on the virtual asset in the production computing environment that is associated with a different, or new, type of connectivity, or operational scenario, other than the specific type of connectivity allowed for the virtual asset in the production computing environment.
In light of the situation described above, currently, the vulnerability analysis and verification process, at best, is incomplete and only provides reasonably accurate data if the virtual assets are deployed in the production computing environment exactly as intended and no changes are made to the type of connectivity, and operational parameters, expected to be provided to the virtual assets. Consequently, serious vulnerabilities may still be present in the virtual assets that will only be revealed if there is a change in the type of connectivity and/or operational scenario associated with the virtual asset. However, if there is a change in the type of connectivity and/or operational scenario associated with the virtual asset, an unexpected vulnerability may well result and, as noted above, if this vulnerability is exploited the damage done may well be irreparable and devastating.
What is needed is a method and system for providing vulnerability analysis and verification management that extends beyond the expected connectivity restrictions and production computing environment associated with a given virtual asset and allows the virtual asset to be verified to be free of vulnerabilities in a broad range of connectivity and operational environments beyond that expected and that can be tested for in the production computing environment.